Method for enabling a client to specify the characteristics of an image to be downloaded from a server

ABSTRACT

A method for serving an image from a server to a client, e.g., a computer having a browser or other graphics viewing engine. The user of the client first specifies a set of one or more bitmap characteristics for an image transfer, with at least one of the bitmap characteristics including a number of bits per pixel. Preferably, this specification is accomplished using an applet or other piece of code that is downloaded to the client from the server. Later, when the server receives a client request that includes data identifying a specified bitmap characteristic, a server processing routine (e.g., a servlet) generates a version of the image that conforms to the specified bitmap characteristic. This version is then delivered back to the client in response to the original request. In this way, the user of the client machine can control the particular characteristics of the image files that are delivered to his or her machine.

BACKGROUND OF THE INVENTION

[0001] 1. Technical Field

[0002] The present invention relates generally to transmission of imagecontent in a computer network and, in particular, to a method forenabling a user of a client machine to negotiate the format of an imageto be transferred to the client machine from a server in the network.

[0003] 2. Description of the Related Art

[0004] The World Wide Web is the Internet's multimedia informationretrieval system. In the web environment, client machines effecttransactions to web servers using the Hypertext Transfer Protocol(HTTP), which is a known application protocol providing users access tofiles (e.g., text, graphics, images, sound, video, etc.) using astandard page description language known as Hypertext Markup Language(HTML). HTML provides basic document formatting and allows the developerto specify “links” to other servers and files. In the Internet paradigm,a network path to a server is identified by a so-called Uniform ResourceLocator (URL) having a special syntax for defining a network connection.Use of an HTML-compatible browser (e.g., Netscape Navigator or MicrosoftInternet Explorer) at a client machine involves specification of a linkvia the URL. In response, the client makes a request to the serveridentified in the link and, in return, receives in return a documentor,other object formatted according to HTML. A collection of documentsor objects supported on a web server is sometimes referred to as a website.

[0005] Many web pages include high resolution images or graphics. Whenit is desired to transmit an image over the Internet, typically eitherthe entire image is transferred or, alternatively, a smaller,low-resolution version is served. An example of a low-resolution imageis a thumbnail image, which the user may review and then select tocontrol the browser to fetch the full resolution image. Transmission ofa thumbnail image instead of the full resolution image it representsconserves significant bandwidth and network resources.

[0006] It is also known in the prior art to provide software routines atboth a client and a server in a distributed computer network to enablethe amount of data in a graphical image that is to be transmitted (i.e.from server to client) to be customized in according with client and/orserver-supplied information. Such a technique is described in U.S. Pat.No. 5,764,235 to Hunt et al. In this patent, each of the client andserver include a dedicated handshake process that allows the machines tofirst determine whether they both support the image customizationfunctionality. If so, then the server may then use an imagecustomization process on images to be transmitted to the client toselectively modify the amount of data and the format of the graphicalimage files to be sent to the client in response to a request for theimage. In performing the image customization process, the server makesuse of server image control data and/or client image control data. Theclient image control data is data or information obtained from theclient that is useful in determining both the suitable amount of dataand/or format for the graphical image files to be sent. Typically, suchdata includes user data and client system data. The user data mayinclude user preference, intended use, or a specific quality level. Theclient system data includes type of compression supported, transmissionperformance criteria, and equipment data (e.g., display format, printerformat, or the like).

[0007] While the technique illustrated in Hunt et al. reduce imagetransmission time and save network bandwidth, the approach has certaindisadvantages. Foremost, the technique proposed by Hunt et al. envisionsthat a given graphical image file be processed prior to receipt of theclient request. According to the patent, the image file is processed tocreate a modified image file that is partitioned into various additivesegments. As more and more of the segments are added together, a betterquality image is created. Thus, for example, a first segment can be usedfor displaying the image as a high quality, thumbnail size image or alow quality, feature size image. By combining this segment with anothersegment, the resulting image can be used as a high quality, feature sizeimage or a low quality, full screen size image.

[0008] Preprocessing the image in accordance with the teachings of theHunt et al. patent effectively offsets the advantages that are otherwiseachieved by sending the customized images. In particular, the generationof the custom segments consumes both processing and storage resources atthe server, thus minimizing the value of the technique. In addition, thetypes of client image control data identified in the patent do notafford the user of the client machine sufficient flexibility to controlthe characteristics of the actual image transferred.

[0009] The present invention addresses these deficiencies of the priorart.

BRIEF SUMMARY OF THE INVENTION

[0010] It is a general object of the present invention to enable a userof a client machine to negotiate the bitmap format of a given image tobe transferred to the machine from a server in a computer network.

[0011] A more specific object of this invention is to enable a user of aclient browser to specify given bitmap format characteristics whenmaking a request for a high resolution image supported on the server. Inoperation, the image is processed “on-the-fly” as it is served inresponse to the client request to produce a version customized accordingto the specific request.

[0012] By identifying specific image bitmap format characteristics, asignificant reduction in transmission time and file storage space can beachieved.

[0013] Preferably, the type of bitmap format characteristics that may bespecified are quite varied. One particular type of format characteristicis the number of bits per pixel in the image, which is a measure ofcolor depth. Other types of image format characteristics that may bespecified when making a request for an image supported on the serverinclude a type of compression method (lossy vs. non-lossy), image loss,or the type of target device.

[0014] According to another feature of the invention, the user of theclient machine may simply make a coarse selection of the quality of theimage he or she desires as a function of the time required to downloadthe particular image file. Preferably, this selection is made using aslider control. Once the slider is set, the particular selection is thentranslated into appropriate control parameters to select the bits perpixel and bitmap compression format best suited to adapt the images fortransfer to the client.

[0015] The foregoing has outlined some of the more pertinent objects andfeatures of the present invention. These objects should be construed tobe merely illustrative of some of the more prominent features andapplications of the invention. Many other beneficial results can beattained by applying the disclosed invention in a different manner ormodifying the invention as will be described. Accordingly, other objectsand a fuller understanding of the invention may be had by referring tothe following Detailed Description of the Preferred Embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] For a more complete understanding of the present invention andthe advantages thereof, reference should be made to the followingDetailed Description taken in connection with the accompanying drawingsin which:

[0017]FIG. 1 is a simplified illustration of a client-server environmentin which the present invention may be implemented;

[0018]FIG. 2 is a block diagram of the various functional components ofthe image transfer mechanism of the present invention;

[0019]FIG. 3 is a simplified illustration of an image that is decomposedinto a plurality of pixel elements;

[0020]FIG. 4 is a flowchart illustrating a client-side operation of thepresent invention;

[0021]FIG. 5 illustrates a representative client-side user interface foruse in the present invention; and

[0022]FIG. 6 is a flowchart illustrating a server-side operation of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0023] The present invention may be implemented in any clientserver-based computer network operating environment. In the preferredembodiment described below, the invention is illustrated in the contextof an open Internet networking environment wherein users of clientmachines interconnect to servers that support content to be downloaded,typically via a web-based protocol such as HTTP. While this is apreferred operating environment, one of ordinary skill will appreciatethat the principles of the present invention are not limited to use forWeb content retrieval between a web site and a client browser. Thetechniques are useful in any environment in which it is required totransfer an image file between a server and a client, irrespective ofthe given transfer protocol, system configuration or networkingenvironment.

[0024] With the above caveat, a representative system in which thepresent invention is implemented is illustrated in FIG. 1. A pluralityof Internet client machines 10 are connectable to a computer networkInternet Service Provider (ISP) 12 via a network such as a dialuptelephone network 14. As is well known, the dialup telephone networkusually has a given, limited number of connections 16 a-16 n. ISP 12interfaces the client machines 10 to the remainder of the network 18,which includes a plurality of web content server machines 20. Network 18typically includes other servers for control of domain name resolution,routing and other control functions. A client machine typically includesa suite of known Internet tools, including a Web browser, to access theservers of the network and thus obtain certain services. These servicesinclude one-to-one messaging (e-mail), one-to-many messaging (bulletinboard), on-line chat, file transfer and browsing. Various known Internetprotocols are used for these services. Thus, for example, browsing iseffected using the Hypertext Transfer Protocol (HTTP), which providesusers access to multimedia files using Hypertext Markup Language (HTML).The collection of servers that use HTTP comprise the World Wide Web,which is the Internet's multimedia information retrieval system.

[0025] A representative web server 20 comprises one or more processors22 (e.g., ×86, Pentium-based, RISC-based, or the like), a system memory25 for supporting an operating system 24 (e.g., AIX, Windows NT, Windows'98, Linux, or the like) and a web server program 26 (e.g., IBMNetfinity, WebSphere, or the like). An application programming interface(API) 28 or other interface provides extensions to enable applicationdevelopers to extend and/or customize the core functionality thereofthrough software programs including plug-ins, servlets, and the like.One such program is an image transfer mechanism 30 of the presentinvention. The mechanism provides server-side processing of images assuch objects are served to a particular client machine (and, inparticular, to a given user at the client machine).

[0026] Referring now to FIG. 2, the image transfer mechanism may beimplemented most conveniently in software, namely, as a set ofinstructions that are executed in a processor. Thus, for purposes ofillustration, FIG. 2 shows the mechanism 30 as being resident in systemmemory (e.g., RAM) 25 associated with a given processor 22 operatingwithin the server platform 20. The image transfer mechanism 30 includesseveral functional components: an applet 32, a manager 34, a set ofclient response routines 36 a-n, and a dynamic image processor 38. Theapplet 32 comprises a set of Java class files and is adapted to beserved to given client machines in the network. The applet 32 isexecutable in the user's client machine using local resources, e.g., aweb browser or other graphics viewer. As will be seen, the applet isdesigned for execution on the client machine by a particular user togenerate a set of image format data that defines the transfercharacteristics for a given image. Alternatively, the functionality ofthe applet 32 may be a client-side plug-in, may be built in to a clientbrowser or provided as a standalone program. Implementation as an appletis desirable as it enables the image transfer mechanism to reside on agiven server.

[0027] Generally, the image transfer mechanism enables a user of clientmachine, e.g., a user of a HTTP-compliant web browser, to specify theparticular transfer characteristics of an image to be served to theclient machine from a server in the computer network. By way of briefbackground, and with reference to FIG. 3, a given image 40 to be servedto the client machine for display (e.g., on a raster-based image displaydevice, conventionally a CRT) or for printing comprises an equal amountof picture elements, called pixels 42. The amount of color informationcontained in each pixel is determined by the pixel's depth, or bits perpixel. The more bits per pixel, the more colors, shades, and hues apixel may contain. Thus, for example, at one bit per pixel, the pixelcontains only two colors; however, at eight bits per pixel, the pixelmay contain 256 colors. Of course, the more colors in an image, thebetter the resolution and image quality.

[0028]FIG. 4 illustrates a flowchart describing the basic client-sideoperation of the present invention. The routine begins at step 44 todetermine whether the user of the client machine desires to negotiate agiven image transfer format. If not, the routine cycles. If, however,the user desires to customize the image transfer characteristics (of agiven image, or of all images on a page, or the like), the outcome ofthe test at step 44 is positive. Control then continues at step 46 withthe display of a user dialog 48 such as illustrated in FIG. 5. The userdialog 48 preferably is generated by the applet of the image transfermechanism. Alternatively, the user dialog may be accessed from a browserpull-down menu (if the functionality is built into the browser), or bysome other means (e.g., a server-side CGI-based scripting function).Nevertheless, this dialog is merely representative and should not betaken to limit the scope of the present invention.

[0029] The user dialog 48 includes a number of graphical controls. Amaster slider 50 has a number of control positions as determined by therelative placement of the slider. Typically, the slider is positionedusing a conventional drag operation, using an input device such as amouse or trackpad device. As illustrated, the master slider 50 has atopmost position, for the fastest download, and a bottommost position,for the slowest download. As can be seen, the fastest download isassociated with the worst quality image, while the slowest download isassociated with the best quality image. The user may select a givenspeed versus quality characteristic by positioning the slider asdesired.

[0030] As also seen in FIG. 5, the user dialog 48 includes a number ofadditional controls that may be selected by the user to control aparticular image transfer characteristic. Thus, for example, the dialogincludes a set of radio buttons 52 that enable the user to select aparticular color depth. A secondary slider 54 may be used to select agiven number of dots per inch, which is a printer characteristic.Another set of radio buttons 56 may be used to identify a given type ofbitmap compression format. In this example, which is merelyrepresentative, the user dialog 48 presents four different types ofbitmap compression: TIFF (Tagged Image File Format), RLE (Run-LengthEncoding), GIF (Graphics Interchange Format), and JPEG (JointPhotographic Experts Group). As is well-known, TIFF, RLE and GIF arerepresentative lossless types of image compression, while JPEG is arepresentative lossly data compression technique. When the user selectsthe particular type of compression format, a color ratio value isdisplayed in the field 58. The dialog also includes various controlbuttons such as OK, Cancel and Help.

[0031] Returning now back to the flowchart of FIG. 4, the client-sideroutine then tests at step 60 to determine whether the user haspositioned the master slider 50. If the result of the test at step 60 isnegative, the routine continues at step 62 to store the user-selectedimage transfer characteristics (i.e. the bit per pel setting, the bitmapcompression format, and the like). These values may be convenientlystored in a file on the client. If the result of the test at step 60 ispositive, the routine branches to step 64 to calculate the bits per peland the bitmap compression format that best approximates the user'sselection. Control then continues at step 65 to store the generatedvalues. The routine then tests at step 66 to determine whether an imagehas been requested. An image may be requested in any number of ways. Inan illustrative embodiment, the image is requested as part of a webpage. When the outcome of the test at step 66 is positive, the routineretrieves the image transfer characteristic data previously stored. Thisis step 68. At step 70, the image transfer characteristic data isdelivered with the client request to the server. This completes theclient-side processing.

[0032] One of ordinary skill will appreciate that the image transfercharacteristic data may be generated at the client machine and thenuploaded to the server (at which the image is hosted) in a communicationseparate from the actual request for the image. Thus, for example, thedata may be uploaded and stored at the server in a file uniquelyassociated with identifying information of the user (e.g., userid andpassword).

[0033]FIG. 6 is a flowchart illustrating the server-side processing of aclient request for the image. As noted previously, in the preferredembodiment, a high resolution version of the image is stored on orotherwise accessible from the server. The routine begins at step 72 betesting to determine whether a client request (e.g., an HTTP GETrequest) has been received. If not, the routine cycles. If, however, aclient request has been received, the routine continues at step 74 todetermine whether the request includes any data specifying the imagetransfer characteristics. If the outcome of the test at step 74 isnegative, the routine branches to step 76 and returns the requestedfile(s) without processing the image. If, however, the outcome of thetest at step 74, the routine continues at step 78 to pass the request tothe manager routine 34 of the image transfer mechanism. At step 80, themanager 34 launches an instance of a client response routine 36.According to a preferred embodiment, each client response routineprocesses a given client request and is implemented as a Java servlet.Alternatively, the client response routine may be implemented asstandalone native code.

[0034] Referring now back to FIG. 6, at step 82 the client responseroutine parses the image transfer data received from (or otherwiseassociated with) the client request (e.g., if such data were uploaded toand stored at the server earlier). After parsing the data stream, theclient response routine returns control back to the manager 34, passingback the image formatting data at step 83. At step 84, the managerretrieves a requested image file. At step 86, the manager then passesthe requested image file and the image formatting data to the dynamicimage processor 38 of the image transfer mechanism.

[0035] Control then continues at step 88. At this step, the dynamicimage processor 38, using the formatting data an input, transforms theimage into a version that best matches the user's specification. Thus,for example, if formatting data specifies a RLE encoding as the bitmapcompression format, the dynamic image processor 38 encodes the imagewith this compression format. The dynamic image processor alsotransforms the image according to the requested color depth (i.e. bitsper pel) value of the formatting data. The output of the dynamic imageprocessor is then passed at step 90 to other server control processes asrequired. Thus, for example, the other server control process may be aroutine that generates a data stream to be returned to the client thatincludes other data besides the processed image. This completes theserver-side processing.

[0036] The present invention provides many advantages over the priorart. By allowing the user of the client machine to select the colordepth, namely the bits per pel, the user has significantly more controlover how the image is actually delivered from the server. To provide aconcrete example, if the user of the client machine downloads an 8″×11″bitmap of 24 bits per pel for a printer having a resolution of 360×360dots per inch, the total amount of the download is approximately 33Mbytes. Using the present invention, the user can modify the bits perpel desired for the download, which greatly reduces the file size andthus the download time. Thus, for example, if the user designates 8 bitsper pel, this has the effect of reducing the effective download size byone-third. Thus, the time required to transmit the file from the serverto the client will be increased by a factor of 3×. In like manner, theuser can alter the compression technique to facilitate a more efficientdownload given the available network and/or local resources.

[0037] The above-illustrated interface identifies a number of bitmapcompression techniques that may be customized by the user of the clientmachine. One of ordinary skill in the art will recognize, however, thatthere are numerous other types of graphics file formats that mayprocessed in like manner. Thus, the present invention is not limited tothe formats identified in the representative interface. Otherconventional compression formats that may be implemented include,without limitation: PNG (Portable Network Graphics), BMP (MicrosoftWindows device-independent bitmap format), DIB (Device IndependentBitmap), PCX, WMF (Windows Metafile Format), PAL (Palette File Format),and others. As noted above, preferably the dynamic image processorincludes or has access to the particular bitmap processing algorithmthat is made available to the user for customizing the file formatrequest.

[0038] A representative client on which the applet (or equivalentclient-side code) is run is a personal computer, notebook computer,Internet appliance or pervasive computing device (e.g., a PDA or palmcomputer) that is ×86-, PowerPC®- or RISC-based. The client includes anoperating system such as IBM® OS/2®, Microsoft Windows, MicrosoftWindows CE or PalmOS. As noted above, the client includes a suite ofInternet tools including a Web browser, such as Netscape Navigator orMicrosoft Internet Explorer, that has a Java Virtual Machine (JVM) andsupport for application plug-ins or helper applications. The applet isexecutable in the JVM in a well-known manner.

[0039] Generalizing, the above-described functionality thus preferablyincludes a server side piece and a client side piece. The server sidepiece comprises the manager, the set of client response routines, andthe dynamic image processing routine. As has been noted, the server-sideroutines may be implemented as a Java servlet or as standalone nativecode. Some of the image processing routines may be commerciallyavailable programs that provide known image compression functions. Asalso described above, the client side piece is preferably a Java applet,although the client piece may be written in native code. In either case,preferably the above-described functionality is implemented in softwareexecutable in a processor, namely, as a set of instructions (programcode) in a code module resident in the random access memory of thecomputer. Until required by the computer, the set of instructions may bestored in another computer memory, for example, in a hard disk drive, orin a removable memory such as an optical disk (for eventual use in a CDROM) or floppy disk (for eventual use in a floppy disk drive), ordownloaded via the Internet or other computer network.

[0040] In addition, although the various methods described areconveniently implemented in a general purpose computer selectivelyactivated or reconfigured by software, one of ordinary skill in the artwould also recognize that such methods may be carried out in hardware,in firmware, or in more specialized apparatus constructed to perform therequired method steps.

[0041] Further, as used herein, a Web “client” should be broadlyconstrued to mean any computer or component thereof directly orindirectly connected or connectable in any known or later-developedmanner to a computer network, such as the Internet. The term Web“server” should also be broadly construed to mean a computer, computerplatform, an adjunct to a computer or platform, or any componentthereof. Of course, a “client” should be broadly construed to mean onewho requests or gets the file, and “server” is the entity whichdownloads the file.

[0042] Having thus described our invention, what we claim as new anddesire to secure by Letters Patent is set forth in the following claims.

1. A method for serving an image from a server to a client, comprising the steps of: specifying a set of one or more bitmap characteristics for an image transfer, at least one of the bitmap characteristics including a number of bits per pixel; responsive to a client request, generating a version of the image that conforms to the specified bitmap characteristic; and serving the version of the image back to the client.
 2. The method as described in claim 1 wherein the set of bitmap characteristics includes a bitmap compression format.
 3. The method as described in claim 3 wherein the step of generating the version of the image includes processing the image according to the specified bitmap compression format.
 4. The method as described in claim 2 wherein the bitmap compression format is lossy.
 5. The method as described in claim 2 wherein the bitmap compression format is non-lossy.
 6. The method as described in claim 1 wherein the step of specifying the set of bitmap characteristics include setting a graphic control.
 7. The method as described in claim 1 wherein the graphic control is a: slider having first and second positions and a plurality of intermediate positions.
 8. The method as described in claim 7 wherein the first position selects a subset of bitmap characteristics for a fastest download and lowest quality version of the image.
 9. The method as described in claim 7 wherein the second position selects a subset of bitmap characteristics for a slowest download and highest quality version of the image.
 10. A method for serving an image from a server to a client, comprising the steps of: storing an image at the server; at the client, specifying a set of one or more bitmap characteristics for an image transfer, at least one of the bitmap characteristics including a number of bits per pixel; at the server, responsive to a client request that includes data identifying a specified bitmap characteristic, generating a version of the image that conforms to the specified bitmap characteristic; and serving the version of the image back to the client.
 11. The method as described in claim 10 wherein the client is a computer having a browser for issuing the client request.
 12. The method as described in claim 10 wherein the bitmap characteristics include a bitmap compression format.
 13. The method as described in claim 10 wherein the bitmap characteristics include a number of dots per inch on a printer associated with the client.
 14. The method as described in claim 10 wherein the image is stored at the server in a high resolution format.
 15. A method for serving a web page having an image, comprising the steps of: at a web server, receiving a request for the web page; and parsing the request to identify given data identifying a requested bitmap characteristic; if the request includes the given data, generating a version of the image that conforms with the requested bitmap characteristic; and serving the web page with the version of the image.
 16. The method as described in claim 15 wherein the requested bitmap characteristic is a number of bits per pixel.
 17. The method as described in claim 15 wherein the requested bitmap characteristic is a number of bits per pixel and a given bitmap compression technique.
 18. A computer program product in a computer-readable medium for serving bitmap-adjusted images to a plurality of web clients, comprising: code executable at a given web client for enabling a user to specify a bitmap characteristic; means operative upon receipt of a given request from a web client for parsing the given request to determine whether the user has specified a bitmap characteristic; means responsive to a positive determination for generating a bitmap-adjusted version of the image; and means for serving the bitmap-adjusted version of the image in response to the given request.
 19. The computer program product as described in claim 18 wherein the bitmap characteristic is a number of bits per pixel.
 20. The computer program product as described in claim 18 wherein the code executable on the given web client is an applet.
 21. The computer program product as described in claim 18 wherein the means for parsing includes a manager routine and a set of client response routines, wherein a given client response routine is launched by the manager upon receipt by the manager of a given client request.
 22. The computer program product as described in claim 18 wherein the means for generating includes an image processor.
 23. The computer program product as described in claim 22 wherein the image processor includes means for processing the image according to a given bitmap compression technique.
 24. A server operative in a computer network, comprising: at least one image stored in a high resolution format; an applet deliverable to a given web client for execution on the web client by a user to generate given data, the given data identifying a number of bits per pixel; code responsive to receipt of a given request for the image for parsing the given request to identify the given data; and code responsive to the identification for generating a version of the image having a reduced number of bits per pixel.
 25. The server as described in claim 24 further including code for serving the version of the image having the reduced number of bits per pixel.
 26. A computer program product electronically deliverable to a web client for execution in a browser virtual machine, comprising: code for generating a user dialog including a master graphic control, the master graphic control having at least first and second positions and a plurality of intermediate positions; and code responsive to placement of the control at the first position for generating a set of bitmap characteristics for a fastest download and lowest quality version of an image; and code responsive to placement of the control at the second position for generating a set of bitmap characteristics for a slowest download and highest quality version of the image. 